當我們在做 RAG 的時候，要能找到使用者問題和正確的參考知識，靠的是 語意搜尋 (semantic search)。這背後的關鍵，就是把文字轉換成向量，將語意映射到高維空間，才能透過相似度搜尋來找到最相關的答案。

而這個把文字映射成向量的模型，就是 Embedding model。

🔑 Embedding 模型的重要性

不同的 embedding 模型是靠 不同的 tokenizer 與語料 訓練而成，因此挑選正確的模型很重要。例如：

• 英文的 embedding 模型就不適用於中文場景。
• 特定場域的話泛用型的模型可能效果不佳，要找對應的專有領域模型，或是自行Fine-tuning。

此外，Embedding 的檢索品質還取決於以下幾個因素：

1. 語言支援：是否支援繁體中文、多語言。
2. 向量維度 (dimensionality)：維度越高，表達能力越強，但計算與儲存成本也越高。
   • 384 維（如 MiniLM）：快、便宜，但語意表達較弱。
   • 768 維（如 XLM-R）：平衡。
   • 1024/1536 維（如 OpenAI text-embedding-3-large, BGE-m3）：表達力強，但成本高。
3. Pooling 策略：影響語義表示的完整性和準確性，進而影響檢索的召回率和精確度。常見有Mean Pooling, CLS Token Pooling，以及Last Token Pooling。

Pooling較為複雜，我請Claude幫忙整理一張表格，希望能幫助讀者快速釐清差異。

⚙️ Embedding 模型的典型架構

多數 Embedding 模型屬於 Encoder-only (BERT family)，這類架構最適合產生密集向量。

第一步通常是 tokenizer，因為不同的 tokenizer 決定了文本如何被拆解為 token → 最後影響檢索效果。

要在地端執行，一般可以使用 SentenceTransformers 套件來安裝，如果遇到困難，也可以到Huggingface上去直接把Embedding 模型下載下來後使用，假設我們要使用BAAI/bge-m3這顆embedding，我們可以到Huggineface-BGE-m3的首頁，點選Filse and Version如下圖:

下載裡面的結構包含以下：

• 1_Pooling
• config.json
• modules.json
• pytorch_model.bin
• special_tokens_map.json
• tokenizer.json
• tokenizer_config.json

這些結構裡面涵蓋了模型維度、pooling 策略、tokenizer 規則等關鍵資訊。

筆者建議至少可以透過 SentenceTransformers 套件解析模型，快速理解模型設定。

🔍 模型拆解與比較：BGE-M3 vs all-MiniLM-L6-v2

我們就利用SentenceTransformers 套件來解析模型給大家做參考，我們選擇 BGE-M3（大型、多語言、長文本）與 all-MiniLM-L6-v2（輕量、英文短文本）。
語法如下

# 記得要先install
# 匯入 SentenceTransformer 套件
from sentence_transformers import SentenceTransformer

# 載入 embedding 模型
# - 如果要用 all-MiniLM-L6-v2: "all-MiniLM-L6-v2"
# - 如果要用 BGE-m3: "BAAI/bge-m3"
model = SentenceTransformer("all-MiniLM-L6-v2")

# 檢查模型的基本架構
# 會顯示 Transformer backbone, Pooling 層, Normalization 層等資訊
print(model)

# 取得模型的第一個模組 (通常是 Transformer 本體)
first_module = model._first_module()

# 進一步查看 Transformer 的 embedding 層
# - word_embeddings: 詞嵌入矩陣 (詞彙表大小 x 向量維度)
# - position_embeddings: 位置嵌入，用來表示 token 在句子中的位置
# - token_type_embeddings: 區分不同句子 (如句子 A / 句子 B)，部分模型會使用
# - LayerNorm: 正規化層，幫助訓練穩定
# - dropout: 防止過擬合
embeddings = first_module.auto_model.embeddings
embeddings

以下整理兩者的細節：

📌 BGE-M3

• Backbone: XLM-Roberta
• 最大序列長度: 8192 tokens
• 嵌入維度: 1024
• 詞彙表大小: 250k+
• Pooling 策略: 使用 [CLS] token 向量
• Normalization: L2 normalization
• 多語言支援: ✅
• 適合場景: 長文件檢索、跨語言應用、企業級知識庫

📌 all-MiniLM-L6-v2

• Backbone: BertModel (MiniLM 精簡版)
• 最大序列長度: 256 tokens
• 嵌入維度: 384
• 詞彙表大小: 30k+
• Pooling 策略: 使用 mean pooling（所有 token 平均）
• Normalization: L2 normalization
• 多語言支援: ❌（主要英文）
• 適合場景: 短文本檢索、英文 QA、輕量化應用

📊 參數對照表

👉 總結來說：

• BGE-M3 提供更長的序列長度、更高維度與多語言能力，適合需要處理大規模、多語言、長文件的企業應用。
• MiniLM-L6-v2 輕量且快速，適合小型專案或英文為主的檢索任務。

🈶 繁體中文 Embedding 的選擇

在繁體中文的應用場景，建議選擇 支援多語言 的 embedding 模型：

• BGE-m3 → 筆者推薦，支援多語言，效果佳，可自行 fine-tuning。
• OpenAI text-embedding-3-large/small → 高品質，但需雲端 API，成本依 token 數增加。
• 台灣社群的中文專門模型 → 例如 TaiwanLLM 釋出的 embedding 模型，但品質需個案測試。

有興趣的朋友可以參考ihower大大的使用繁體中文評測各家 Embedding 模型的檢索能力

🔗總結

• Embedding 是 RAG 的基石，檢索品質取決於模型好壞。
• 模型選擇需考慮語言支援、維度大小、相似度度量與 pooling 策略。
• 繁中應用建議 BGE-m3 或其他多語言模型。

• 補充: 企業選擇上其實常會遇到專有名詞通用型的embedding無法了解，因此是否能做fine-tuning來加強檢索功能也是一項重要的任務；除此外還要考量效能與成本，可能會需要能做量化的embedding模型以達到輕量化與加速的動作，後續優化章節再來討論。

👉 下一篇將介紹 向量資料庫 (Vector Database)，筆者整理一些現行流行的向量資料庫做比較討論。